fix(graph): persistent DAG mode panics on startup (shared Sled Db)#101
Merged
Conversation
enable_dag_persistent and sled_with_dag previously called sled::open on the same path the triple store already had open, which deadlocks on the file lock (only on real --db paths; :memory: masked it in tests). Now the DAG tree is opened on the triple store's existing sled::Db via a new SledDagBackend::from_db, reached through a StorageBackend::as_any downcast to SledBackend. Adds a regression test reproducing the lock self-conflict. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
ApiliumDevTeam
added a commit
that referenced
this pull request
Jun 23, 2026
fix(graph): persistent DAG mode panics on startup (shared Sled Db)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
aingle-cortex --db <path>(any persistent run with thedagfeature, including the MCP server--mcp --db <path>) panicked on startup:Root cause
The triple store opened the Sled DB via
sled::open(path)(holding the file lock), thenGraphDB::enable_dag_persistent(path)did a secondsled::open(path)on the same path for the DAG backend. The two opens did not share the instance, so the second failed to acquire the lock. The DAG was meant to share the triple store's Db (oneDb, a separate"dag"tree) but the implementation re-opened the path instead.This only manifested with a real
--db <path>; every test uses:memory:(no file lock), which is why it was never caught. Persistent DAG mode effectively never started.Fix
Share the triple store's
sled::Dbhandle (cheaply clonable —Arcinside) with the DAG backend instead of re-opening the path:StorageBackendgainsas_any()(downcasting support); implemented by all four backends.SledBackend::db()exposes the handle;GraphStore::backend_as_any()reaches it.SledDagBackend::from_db(&Db)opens the"dag"tree on an existingDb.GraphDB::enable_dag_persistent(and the same latent bug insled_with_dag) now downcast toSledBackendand open the DAG tree on the sharedDb, falling back to path-open only for non-Sled backends.Test plan
enable_dag_persistent_shares_sled_db_no_lock— failed before (the exact lock error), passes after.cargo test -p aingle_graph --features dag— 77 passed.cargo build -p aingle_cortex --features "mcp dag"and default — compile clean.aingle-cortex --mcp --db <path>now boots (serverInfo on stdout, "DAG persistence enabled (Sled)", no panic). Verified persistence across process restart: write a triple in one process, read it back (+ signeddag_history) in a fresh process on the same DB.Notes
sled_with_dag, which had the identical double-open.